• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    METHOD IMPLEMENTED BY COMPUTER,NON TRANSIENT STORAGE MEANS COMPUTER-READABLE SYSTEM.Implementations of the invention include receiving data fromtransaction associated with the transaction, the transaction data comprising:data representative of a plurality of assets, a firstappointment that hides a random first number and a value oftransaction transaction, a second commitment that hides a secondrandom number and a change, the transaction amount and a thirdrandom number both encrypted by a public key of the secondnode based on a probabilistic homomorphic encryption scheme(HE), the change and a fourth random number both encrypted bya public key of the first node based on the probabilistic HE scheme and a proof of zero knowledge (ZKP); determine, based on the ZKP, whether the transaction is valid based on determining whether the first numberrandom is equal to the third random number, the second numberrandom equals the fourth random number and the transaction amounthidden in the first appointment is equal to the transaction amount.encrypted by the public key of the second node.
    公开号:BR112019016474A2
    申请号:R112019016474-0
    申请日:2018-12-21
    公开日:2021-06-29
    发明作者:Wenbin Zhang；Baoli Ma；Huanyu Ma
    申请人:Alibaba Group Holding Limited；
    IPC主号:
    专利说明:

    [001] [001] Trust protocol networks (blockchain), which may also be called trust protocol systems, consensus networks, distributed accounting system networks, or trust protocol, allow participating entities to securely store data and immutable. A trust protocol can be described as a transaction log and multiple copies of the trust protocol are stored across a trust protocol network. Examples of types of trust protocols can include public trust protocols, consortium trust protocols, and private trust protocols. A public trust protocol is open for all entities to use the trust protocol and participate in the consensus process. A consortium trust protocol is a trust protocol where the consensus process is controlled by a pre-selected set of nodes, such as certain organizations or institutions. A private trust protocol is provided to a private entity, which centrally controls read and write permissions.
    [002] [002] Trust protocols can use different record keeping models to record transactions between users.
    [003] [003] A trust protocol includes a series of blocks, each containing one or more transactions executed on the network. Each block can be converted into a registry page, while the trust protocol itself is a complete copy of the registry. Individual transactions are confirmed and added to a block, which is added to the trust protocol. Copies of the trusted protocol are replicated through network nodes. In this way, there is a global consensus on the status of the trust protocol. Furthermore, the trust protocol is open for all nodes to see, at least in the case of public networks. To protect the privacy of trusted protocol users, encryption technologies are implemented.
    [004] [004] In the account balance model, commitment schemes can be used to hide amounts that both parties to a transaction commit to. Commitment schemes can arise from the need for parties to commit to a choice or value and then later communicate that value to the other parties involved. For example, in an interactive Pedersen (PC) commitment scheme, a first user might submit a transaction amount t by sending a commitment value PC(t, r) which is generated based on a random value r. The commitment amount is generated and a second user can only reveal the transaction amount t by getting the random number r. To ensure that the transaction amount is valid, an interval proof can be created to prove that the transaction amount is greater than or equal to zero and less than or equal to the account balance.
    [005] [005] In some cases, multiple transactions can be made from a user. As the proof of range is tied to the remaining account balance, the various transactions need to be verified sequentially in the trust protocol. As such, the corresponding interval proofs can be correctly associated with the account balances remaining after each transaction. However, checking multiple transactions sequentially can be time-consuming. A record keeping model that allows for parallel transaction checks would be beneficial, especially for time-sensitive tasks. BRIEF DESCRIPTION OF THE INVENTION
    [006] [006] Implementations of the invention include computer-implemented methods for non-interactive privacy preservation checks of trust protocol transactions. More particularly, implementations of the invention are directed to a computer-implemented method capable of validating multiple transactions associated with an account of a trusted protocol node in parallel, based on homomorphic encryption and compromise schemes without revealing private information such as value. transaction, account balance, or random numbers to generate appointments, to other trusted protocol nodes.
    [007] [007] In some implementations, actions include receiving transaction data associated with the transaction, the transaction data comprises: data representing a plurality of assets, a first commitment that hides a first random number, and the transaction value of a transaction , a second compromise that hides a second random number and a calculated change based on deducting the transaction amount from the total amount of the plurality of assets, the transaction amount, and a third random number, both encrypted by a public key of the second node based on a probabilistic homomorphic (HE) cryptographic scheme, the alteration and a fourth random number, both encrypted by a public key of the first node based on the HE probabilistic scheme, one or more range proofs, a zero knowledge proof (ZKP ) and a digital signature generated based on a private key corresponding to the public key of the first node; verify the digital signature based on the first node's public key; Determine that one or more scope proofs prove that the transaction amount and change are each greater than or equal to zero; determine that the total value of the plurality of assets is equal to the sum of the transaction and change value; and determine, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the transaction amount hidden in the first commitment equals the amount transaction encrypted by the public key of the second node. Other implementations include systems, apparatus and corresponding computer programs, configured to perform the method actions, encoded in computer storage devices.
    [008] [008] These and other implementations may optionally include one or more of the following assets: the transaction is executed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, first node account and second node account are based on transaction and change amount; each asset plurality is associated with one or more asset types, an asset value hidden in a commitment, and a random number used to generate the commitment; determining that each plurality of assets is associated with the same type of asset; the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic, in which the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the alteration is carried out based on the homomorphism of the commitment scheme; the third random number is encrypted based on the probabilistic scheme HE, treating the transaction amount as a random number, and the fourth random number is encrypted based on the probabilistic scheme HE, treating the change as a random number; the first compromise and the second compromise are generated based on the Pedersen compromise scheme, and the probabilistic HE scheme is an Okamoto-Uchiyama (OU) encryption scheme; ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the UO encryption scheme, and a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the OU encryption scheme; the ZKP is generated and used to determine if the transaction is valid based on the HE probabilistic properties; the determination that the transaction is valid is performed on ZKP basis with no interactions between the first and second nodes through the network outside the trusting protocol.
    [009] [009] The specification also provides one or more computer-readable non-transient storage media coupled to one or more processors and having instructions stored on it that, when executed by one or more processors, cause one or more processors to perform operations accordingly. with implementations of the methods provided here.
    [0010] [0010] The specification further provides a system for implementing the methods provided here. The system includes one or more processors, and a computer-readable storage medium coupled to one or more processors having instructions stored on it that, when executed by one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided here.
    [0011] [0011] The implementations of the subject described in this description can be implemented so as to realize particular advantages or technical effects. For example, implementations of the invention allow the account balance and transaction value of the trust protocol nodes to be private during transactions. The funds transfer recipient does not need to confirm the transaction or use a random number to verify a commitment, transaction validation may be non-interactive. A trust protocol node can validate the transaction based on the HE and commitment schemes to allow proof of zero knowledge.
    [0012] [0012] The described methodology allows for the enhancement of account/data security of various mobile computing devices. Account balance and transaction amounts can be encrypted based on HE and hidden by compromise schemes. As such, a consensus node can update account balances in the registry after the transaction based on the properties of the HE, without revealing the current account balance. As the random number does not need to be sent to a recipient to confirm the transaction, the risk of data leakage can be reduced and fewer compute and memory assets need to be used to manage the random number.
    [0013] [0013] It is understood that the methods according to the specification may include any combination of the aspects and characteristics described herein. That is, the methods as per the specification are not limited to the combinations of features and features specifically described here, but also include any combination of the features and features provided.
    [0014] [0014] Details of one or more implementations of the invention are presented in the attached drawings and in the description below. Other features and advantages of the invention will be apparent from the description and drawings, and from the claims. DESCRIPTION OF DRAWINGS
    [0015] [0015] Figure 1 illustrates an example of an environment that can be used to execute implementations of the invention.
    [0016] [0016] Figure 2 describes an example of a conceptual architecture according to implementations of the invention.
    [0017] [0017] Figure 3 depicts an example of a privacy-protected validation process of a trust protocol transaction based on homomorphic cryptography.
    [0018] [0018] Figure 4 illustrates an example of a trust protocol transaction according to implementations of the invention.
    [0019] [0019] Figure 5 illustrates another example of a privacy-protected validation process of a trust protocol transaction based on homomorphic cryptography.
    [0020] [0020] Figure 6 illustrates an example of a method that can be performed according to implementations of the invention.
    [0021] [0021] Figure 7 illustrates another example of a method that can be performed according to implementations of the invention.
    [0022] [0022] Figure 8 depicts an example of a trusted protocol node that can execute a process according to implementations of the invention.
    [0023] [0023] As the reference symbols in the various drawings indicate similar elements. DETAILED DESCRIPTION OF THE INVENTION
    [0024] [0024] Implementations of the invention include computer-implemented methods for non-interactive privacy preservation checks of trust protocol transactions. More particularly, implementations of the invention are directed to a computer-implemented method capable of validating multiple transactions associated with an account of a trusted protocol node in parallel, based on homomorphic encryption and compromise schemes without revealing privacy information such as number of transactions, account balances, or random numbers to generate appointments, to other trust protocol nodes. In some implementations, the actions include receiving transaction data associated with the transaction, the transaction data comprises: data representing a plurality of assets, a first commitment that hides a first random number and a transaction transaction value, a second compromise that hides a second random number and a calculated change based on deducting the transaction amount from a total amount of the plurality of assets, the transaction amount and a third random number encrypted by a public key of the second node based on a scheme of probabilistic homomorphic cryptography (HE), the alteration and a fourth random number, both encrypted by a public key of the first node based on the probabilistic scheme HE, one or more interval proofs, a proof of zero knowledge (ZKP) and a signature digital generated based on a private key corresponding to the public key of the first node; verify the digital signature based on the first node's public key; Determine that the scope proofs of one or more series prove that the transaction amount and the change are each greater than or equal to zero; determine that the total value of the plurality of assets is equal to the sum of the transaction and change value; and determine, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the transaction amount hidden in the first commitment equals the amount transaction encrypted by the public key of the second node. Other implementations include systems, apparatus and corresponding computer programs, configured to perform the method actions, encoded in computer storage devices.
    [0025] [0025] To provide more context for implementations of the invention, and as presented above, distributed registration systems (DLSs), which may also be called consensus networks (eg, composed of peer-to-peer nodes), and Trusted protocol networks allow participating entities to be secure, and immutable in carrying out transactions and storing data. Trust protocol is used here to generally refer to a DLS without reference to any particular use case.
    [0026] [0026] A trust protocol is a data structure that stores transactions in such a way that transactions are immutable and can be verified subsequently. A trust protocol includes one or more blocks. Each block in the chain is linked to a previous block immediately before it in the chain, including a cryptographic hash of the previous block. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions, which have already been verified by trusted protocol network nodes, are hashed and encoded in a Merkle tree. A Merkle tree is a data structure in which data in the leaf nodes of the tree is hashed and all hashes in each branch of the tree are concatenated at the root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all the data in the tree. A hash that claims to be from a transaction stored in the tree can be quickly checked to determine if it is consistent with the tree structure.
    [0027] [0027] While a trust protocol is a data structure for storing transactions, a trust protocol network is a network of computing nodes that manages, updates and maintains one or more trust protocols. As shown above, a trust protocol network can be provided as a public trust protocol network, a private trust protocol network, or a consortium trust protocol network.
    [0028] [0028] In a publicly trusted protocol, the consensus process is controlled by nodes of the consensus network. For example, hundreds, thousands, and even millions of entities can participate in a public trust protocol, each operating at least one node in the public trust protocol. Thus, the public trust protocol can be considered a public network in relation to the participating entities. In some examples, most entities (nodes) must sign each block for the block to be valid and added to the trust protocol. For example, the public trust protocol network includes a special peer-to-peer payment network that leverages a distributed registry, referred to as a trust protocol. As noted above, the term trust protocol, however, is used to generally refer to distributed records with no particular reference to any particular trust protocol network.
    [0029] [0029] In general, a public trust protocol supports public transactions. A public transaction is shared with all nodes within the trust protocol, and the trust protocol is replicated across all nodes. In other words, all nodes are in a perfect state of consensus regarding the trust protocol. To reach a consensus (for example,
    [0030] [0030] Implementations of the invention include computer-implemented methods for non-interactive privacy-preservation checks of trust protocol transactions. More particularly, implementations of the invention are directed to a computer-implemented method capable of validating multiple transactions associated with an account of a trusted protocol node in parallel, based on homomorphic encryption and compromise schemes without revealing privacy information such as number of transactions, account balances, or random numbers to generate appointments, to other trust protocol nodes.
    [0031] [0031] According to the implementations of the invention, trust protocol nodes can use a generic account model that can support parallel transaction checks as a method of record keeping. In comparison to the account balance model, trust protocol nodes that adopt the generic account model can keep records of a plurality of assets rather than account balances. Each of the plurality of assets can be associated with at least one asset type, asset ID, or asset value. Asset under the generic account model can be in any form or type, such as cash or fixed. Monetary assets can include real currency or cryptocurrency. In some implementations, fixed assets can be converted to monetary assets associated with a monetary value. The monetary value can then be used to carry out transactions between accounts in a trusted protocol network. For illustration purposes,
    [0032] [0032] To protect data privacy, transactions can be logged into a trust protocol (registry) based on the compromise without revealing the transaction amount or monetary value information associated with the trust protocol user accounts. A commitment scheme can be used to generate a commitment of a transaction amount using a random number. An example of a compromise scheme includes, without limitation, the PC scheme. Since the transaction amount is hidden in the commitment, one or more range tests can be used to prove that the transaction amount does not exceed the trust protocol user account value.
    [0033] [0033] In the account balance model, interval proofs are associated with the account balance. If more than one transaction is made, but not all transactions are validated and recorded in the trust protocol, interval proofs may be associated with incorrect account balances and therefore may be invalid. In comparison, under the generic account model, the account value can be calculated as the sum of a plurality of assets. When a transaction amount is to be transferred between trusted protocol user accounts, at least a portion of the plurality of assets with a combined value greater than or equal to the transaction amount can be used to cover the transaction amount. Additional transfers can be made under the condition that the remaining assets have a combined value greater than the amount to be transferred. Even if transactions are not validated and recorded in the trust protocol, scope proofs that show that the combined value of the remaining assets is greater than, or equal to, the transaction value may still be valid. Therefore, more than one transaction check can be performed in parallel in the generic account model.
    [0034] [0034] According to implementations of the invention, trust protocol transactions can be validated and recorded in a trust protocol (registry) based on commitment, without revealing the transaction account balance, transaction amount or number random used to generate the appointment. A commitment scheme, such as the PC scheme, can be used to generate a commitment of a transaction amount based on a random number. The transaction amount and random number can be encrypted using probabilistic or linear deterministic HE. The transaction amount and random number can also be used to generate a set of values like ZKP to validate the transaction based on the properties of the HE schema used. Transaction commitment amount, encrypted transaction amount and random number, and ZKP can be used by a trusted protocol node to verify that the transaction is valid without the account balance, transaction amount, or random number being revealed.
    [0035] [0035] Figure 1 illustrates an example of an environment (100) that can be used to perform implementations of the invention. In some examples, the example environment (100) allows entities to participate in a public trust protocol (102). The example environment (100) includes computing systems (106), (108) and a network (110). In some examples, the network (110) includes a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (eg, web devices). computing) and back-end systems. In some examples, the network (110) can be accessed through a wired and/or wireless communication link.
    [0036] [0036] In the example described, the computing systems (106),
    [0037] [0037] Figure 2 illustrates an example of a conceptual architecture (200) according to implementations of the invention. The example conceptual architecture (200) includes an entity layer (202), a hosted services layer (204), and a public trust protocol layer (206). In the example shown, the entity layer (202) includes three entities, Entity_1 (E1), Entity_2 (E2) and Entity 3 (E3), each entity having a respective transaction management system (208).
    [0038] [0038] In the depicted example, the hosted services layer (204) includes trusted protocol interfaces (210) for each transaction management system (208). In some examples, a transaction management system (208) communicates with a respective trusted protocol interface (210) over a network (e.g., the network (110) of Figure 1) using a communication protocol (e.g. , secure hypertext transfer protocol (HTTPS)). In some examples, each trust protocol interface (210) provides a communication link between a respective transaction management system (208) and the trust protocol layer (206). More particularly, each trust protocol interface (210) allows the respective entity to conduct transactions recorded in a trust protocol network (212) of the trust protocol layer (206). In some examples, communication between a trusted protocol interface (210) and the trusted protocol layer (206) is conducted using remote procedure calls (RPCs). In some examples, trust protocol interfaces (210) “host” trust protocol nodes to respective transaction management systems (208). For example, the trust protocol interfaces (210) provide the application programming interface (API) for accessing the trust protocol network (212).
    [0039] [0039] As described herein, the Trusted Protocol Network (212) is provided as a peer-to-peer network, including a plurality of nodes (214) that record immutable information in a Trusted Protocol (216).
    [0040] [0040] Figure 3 illustrates an example of a process (300) for the privacy-protected validation of a trust protocol transaction based on HE. At a high level, the process (300) is performed by a user A node (302), a user B node (not shown in Figure 3), and a block chain node (304), also referred to as a node of consensus.
    [0041] [0041] To protect the privacy of the account, user node A (302) can generate commitments for the value of the assets used to cover the transaction. User node A (302) may also generate a transaction transaction value commitment. User node A (302) can also use HE to encrypt the transaction amount, change, and random numbers used to generate the appointments. To check the validity of the transaction, the trust protocol node (304) can compare the transaction amount, the change, and the random numbers hidden in the appointments and encrypted by HE based on a ZKP. If the transaction amount, change, and random numbers match, the transaction is determined to be valid by the trust protocol node (304). More details of the process (300) are discussed in the following description of Figure 3.
    [0042] [0042] At (306), user node A (302) selects a plurality of assets for transferring a transaction amount to user node B. User node A (302) and user node B they can be trusted protocol consensus nodes or user nodes that use the trusted protocol network without participating in the consensus process. As discussed earlier, user node A (302) can use a generic account template to maintain records. Rather than keeping the account balance for recording in the account balance template, the account value of user A's node (302) is measured by the total value of the assets it owns. User node A (302) can select a plurality of assets that have sufficient value to cover the transaction amount. For example, if the transaction amount is 7.5 US dollars, user node A (302) can select one of three assets that are worth 5, 2 and 1 US dollars, respectively, to cover the transaction amount.
    [0043] [0043] In some implementations, each asset can be associated with a transaction address or ID that identifies the corresponding asset. The asset ID can be the asset information hashing. Asset IDs of selected assets k can be represented as ID 1,..., IDk.
    [0044] [0044] At (308), user node A (302) calculates a change based on a total value of the plurality of assets and the transaction value.
    [0045] [0045] In (310), user node A (302) generates a random number corresponding to the transaction amount and a random number corresponding to the change. The random number corresponding to the transaction amount t can be denoted as r. The random number corresponding to change t0 can be denoted r0. In some implementations, a plurality of random numbers can be generated to produce asset value compromises. For example, suppose a1,..., ak are asset values, random numbers that correspond to asset values can be expressed as ra1,…, rak.
    [0046] [0046] In some implementations, the random number r0 can be calculated rather than randomly generated. The calculation can be expressed as r0 = ra1 +... + rak - r, where r is the random number generated to produce commitment for the transaction value t. By using the calculated random number r0, user node A (302) does not need to generate an additional ZKP to prove that the total asset value transferred is equal to the total asset value received. In some implementations, another random number r' can be calculated as r' = r1 +... + rk - r - r0, to help with ZKP.
    [0047] [0047] In (312), user node A (302) generates transaction and change value commitments, and encrypts the corresponding random numbers with probabilistic basis HE. In some implementations, homomorphic commitment schemes such as PC can be used to generate the commitments. Using PC as a non-limiting example, the PC of transaction value t can be generated using the random number r, which can be expressed as PC(r,t) = gr ht, where g and h can be generators of an elliptic curve, and PC(r,t) is a scalar multiplication of curve points.
    [0048] [0048] The random number r can be encrypted using the public key of user node B based on a probabilistic scheme HE, such as an Okamoto-Uchiyama (OU) encryption scheme. It is to be understood that other HE schemes, such as Boneh-Goh-Nissim, can also be used. Using OU as a non-limiting example, the random number can be encrypted based on OU by treating the transaction value t as a random number, which can be expressed as UOB(r,t) = urvt, or simply OUB(t) , where u is a generator of (Z/nZ)* satisfying the conditions that v = un mod n, en = p × q, where p and q are two prime numbers. Probabilistic OR can satisfy the property that OR(a + b) = OR(a) × OR(b), where a and b are the plain text used for OR.
    [0049] [0049] Random number r0 can be encrypted using the public key of user node A (302). The random number can be encrypted based on OR by treating change t 0 as a random number, which can be expressed as OUA (r0, t0).
    [0050] [0050] The ciphertext of the transaction amount can then be expressed as T = (PC (t, r), OUB (r, t)), and the ciphertext of the change can then be expressed as T0 = (PC (t0, t) r0), OR(r0, t0)). Similarly, the ciphertext of the selected active k can be expressed as T i = (PC (ti, ri), OUA (ri, ti)), where i = 1,... k.
    [0051] [0051] In (314), user node A (302) generates one or more interval proofs. In some implementations, a first interval proof, RP1, can be generated to show that the transaction value t ≥ 0.
    [0052] [0052] At (316), user node A (302) generates a ZKP. ZKP can be used to show that the random number and transaction amount hidden in PC(r,t) is the same as the random number and transaction amount encrypted in UOB(r,t), and the random number and the transaction value hidden in the PC (r0, t0) is the same as the random number and the transaction value encrypted in OUA (r0, t0). To generate the ZKP, two random numbers t'1 and r'1 can be selected. The two random numbers can be used to generate three values, which are P = PC (t'1, r'1), P' = OUB (r'1, t'1), P'' = OUA (r'1 , t'1).
    [0053] [0053] At (318), user node A (302) uses a private key to generate a digital signature to sign transaction data. In some implementations, transaction data may include the asset IDs of the selected asset k (ID1,..., IDk), the transaction value cipher (T), the change cipher (T0), the proofs of range (RP1 and RP2), the random number r', and the ZKP.
    [0054] [0054] At (320), user node A (302) sends the digitally signed copy of the transaction data to a trusted protocol network.
    [0055] [0055] At (322), the trust protocol node (304) verifies the digital signature. Verifying the digital signature can be performed to ensure that transaction data is sent by user node A (302).
    [0056] [0056] In (324), the trust protocol node (304) checks if the selected assets are associated with user A's node account. The verification can be based on the asset IDs of the assets.
    [0057] [0057] In (326), the trust protocol node (304) checks that the total value of the plurality of selected assets is equal to the sum of the transaction and change value. In other words, the trust protocol checks that a1 +... + ak = t + t0. As discussed earlier, under the generic account model, assets can be held in the trust protocol like PCs to protect data privacy. Based on PC homomorphism, PC(ra1, a1) × . . . × PC(rak, ak) = PC(ra1 + . . . + rak, a1 + . . . + ak), and PC(r, t) × PC(r0, t0) = PC(r + r0, t + t0). Therefore, showing that PC(ra1, a1) × . . . × PC(rak, ak) = PC(r, t) × PC(r0, t0) × gr’, it can be proved that a1 + . . . + ak = t + t0.
    [0058] [0058] At (328), the trust protocol node (304) checks one or more interval proofs.
    [0059] [0059] At (330), the trust protocol node (304) checks the ZKP. As discussed above, ZKP can be generated to check whether the random number matches the transaction value encrypted using the user node B's public key is the same as the corresponding random number hidden by the PC, and whether the random number corresponding to change encrypted using the public key of user node A (302) is the same as the corresponding random number hidden by the PC. In some implementations, to verify ZKP, the trust protocol node (304) may first compute hash value x as x = Hash (P, P', P''). The trust protocol node (304) can then check whether PC(t'2, r'2) = P × PC(t, r)x, OUB(r'2, t'2) = P' × OUB( r, t)x, PC(t'3, r'3) = P × PC(t0, r0)x and UOA(r'3, t'3) = P'' × OUA(r0, t0)x are all true. If all are true, the example process (300) proceeds to (332). Otherwise, the trust protocol node (304) may reject the transaction.
    [0060] [0060] In (332), the trust protocol node (304) updates the accounts of user node A (302) and user node B. Because the accounts of user node A (302) and user node B maintains the assets as records in the generic account template, after the transaction, the plurality of assets transferred from user A's node (302) can be removed from user A's node account (302). The change can be added back to user A's node account (302). The transaction amount, and the corresponding asset ID can be added as a new asset to user B's node account. In some implementations, the update can be performed based on updating the asset lists held by corresponding node accounts of user A (302) and user node B. In some implementations, the update can be performed based on adding ciphertexts of the transaction amount and changing the encrypted asset values held by user node A (302) and by user node B. Updating the accounts is described in more detail here with reference to Figure 4.
    [0061] [0061] Figure 4 illustrates an example of a trust protocol transaction (400) according to implementations of the invention.
    [0062] [0062] Using the commitment schemes, encryption schemes, and transaction process described here with reference to Figure 3 as an example, user node A (402) can generate transaction data (408), which can include transaction IDs. assets of the selected k assets, ID, ID2,…, IDk.
    [0063] [0063] After the transaction, the selected k assets can be removed from user A's asset account (402). The change can be added back to user node A (402). Therefore, user node A (402) can have the following assets expressed as (IDk + 1, Tk + 1), (IDk +2, Tk +2),…, (IDn, Tn), (ID0, T0) where ID0 represents the asset ID of switch t0.
    [0064] [0064] Before the transaction, user node B (404) has m assets, which can be expressed as (ID1’, T1’), (ID2’, T2’), (IDm’, Tm’). After the transaction, the transaction amount can be added to user node B (404).
    [0065] [0065] Figure 5 represents an example of a process (500) of validation protected by privacy of a trust protocol transaction based on HE. At a high level, the example process (500) is performed by a user A node (502), a user B node (not shown in Figure 5), and a trust protocol node (504), also referred to. as a consensus node. Both user A's node accounts (502) and user B's node account can be based on a generic account template. A transaction, such as a transfer of value, can be done from user node A (502) to user node B. User node A (502) can select one or more account assets that have a greater total value or equal to the transaction amount to cover the transaction. The difference between the total value of one or more assets and the transaction value can be considered as the transaction change left to user node A (502).
    [0066] [0066] To protect the privacy of the account, user node A (502) can generate commitments for the asset values used to cover the transaction and the transaction value using a commitment scheme such as the PC. User node A (502) can also use linear deterministic HE to encrypt random numbers used to generate the appointments. Linear deterministic HE can have the following properties:
    [0067] [0067] At (506), user node A (502) selects a plurality of assets to transfer a transaction amount to user node B. User node A (502) and user node B can be the trust protocol consensus node or user nodes that use the trust protocol network without participating in the consensus process. User node A (502) can select a plurality of assets that have sufficient value to cover the transaction amount.
    [0068] [0068] In some implementations, each asset can be associated with a transaction address or asset ID that identifies the corresponding asset. The asset ID can be the asset information hash. Active IDs of selected k assets can be represented as ID1, . . ., IDk.
    [0069] [0069] At (508), user node A (502) calculates a change based on a total value of the plurality of assets and the transaction value.
    [0070] [0070] In (510), user node A (502) generates a random number corresponding to the transaction amount and a random number corresponding to the change. The random number corresponding to the transaction amount t can be denoted as r. The random number corresponding to change t0 can be denoted r0. In some implementations, a plurality of random numbers can be generated to produce asset value compromises. For example, suppose a1, . . ., ak are asset values, random numbers corresponding to asset values can be expressed as ra1, … , rak.
    [0071] [0071] In some implementations, the random number r0 can be calculated instead of randomly generated. The calculation can be expressed as r0 = ra1 + . . . + rak – r, where r is the random number generated to produce commitment for the value of transaction t. When calculating r 0, user node A (502) does not need to generate an additional ZKP to show that the total value of the transferred asset is equal to the total value of the asset received. In some implementations, a random number r' can be calculated as r’ = r1+ …+ rk – r – r0.
    [0072] [0072] In (512), user node A (502) generates commitments of the transaction and change value, and encrypts the corresponding random numbers based on the deterministic HE. In some implementations, homomorphic commitment schemes such as PC can be used to generate the commitments. Using PC as a non-limiting example, the PC of transaction value t can be generated using the random number r, which can be expressed as PC(r,t) = grht, where g and h can be generators of an elliptic curve, and PC(r,t) is a scalar multiplication of curve points. Likewise, the PC of change t0 can be expressed as PC(r0, t0) = gr0ht0.
    [0073] [0073] The random number r can be encrypted using the public key of user node B based on linear deterministic HE. Linear deterministic HE can be obtained from probabilistic HE, such as
    [0074] [0074] The random number r0 can be encrypted using the public key of user node A. The random number can be encrypted based on linear deterministic HE. The encrypted random number can be expressed as HE (r0).
    [0075] [0075] The ciphertext of the transaction amount t can then be expressed as T = (grht, HEB(r)) and the ciphertext of the change can be expressed as T0 = (gr0ht0, HEA(r0)). Likewise, the ciphertext of selected assets k can be expressed as Ti = (gri hti, HE (ri), where i = 1,..., k.
    [0076] [0076] In (514), user node A (502) generates one or more interval proofs. In some implementations, a first interval proof, RP1, can be generated to show that the transaction value t ≥ 0.
    [0077] [0077] In (516), user node A (502) generates a ZKP. ZKP can be used to show that the hidden random number in PC(r,t) is the same as the encrypted random number in HE(r), and the hidden random number in PC(r0,t0) is the same as the random number encrypted in HE (r0). To generate the ZKP, two random numbers t'1 and r'1 can be selected.
    [0078] [0078] In (518), user node A (502) uses a private key to generate a digital signature to sign transaction data. In some implementations, the transaction data may include the asset IDs of the selected k assets (ID1,..., IDk), the transaction value cipher (T), the change cipher (T0), the proofs range (RP1 and RP2), the random number r' and the ZKP.
    [0079] [0079] At (520), user node A (502) sends the digitally signed copy of the transaction data to a trusted protocol network.
    [0080] [0080] In (522), the trust protocol node (504) verifies the digital signature. Verifying the digital signature can be performed to ensure that transaction data is sent by user node A (502).
    [0081] [0081] In (524), the trust protocol node (504) checks whether the selected assets are associated with user A's node account. The verification can be based on the asset IDs of the assets.
    [0082] [0082] In (526), the trust protocol node (504) checks that the total value of the selected plurality of assets is equal to the sum of the transaction and change value. In other words, the trust protocol node (504) checks that a1 +... + ak = t + t0. As discussed earlier, under the generic account model, assets can be held in the trust protocol like PCs to protect data privacy. Based on the homomorphism of PC, PC, PC(ra1, a1) × . . . × PC(rak, ak) = PC(ra1 + . . . + rak, a1 + . . . + ak), and the PC(r, t) × PC(r0, t0) = PC(r + r0, t + t0). Therefore, showing that PC(ra1, a1) × . . . × PC(rak, ak) = PC(r, t) × PC(r0, t0) × gr’, it can be proved that a1 +... + ak = t + t0.
    [0083] [0083] In (528), the protocol trust node (504) checks one or more interval proofs.
    [0084] [0084] In (530), the protocol trust node (504) checks the ZKP.
    [0085] [0085] In (532), the trust protocol node (504) updates the user node A (502) and user node B accounts. user B maintains assets as records in the generic account template, after the transaction, the plurality of assets transferred from user A's node (502) can be removed from user A's node account (502). The change can be added back to user A's node account (502). The transaction amount, and the corresponding asset ID can be added as a new asset to user B's node account. user A (502) and user node B. In some implementations, the update can be performed based on adding ciphertexts of the transaction amount and changing the values of encrypted assets held by user node A
    [0086] [0086] Figure 6 illustrates an example of a process (600) that can be performed according to implementations of the invention. For clarity of presentation, the following description generally describes method 600 in the context of the other figures in this description. However, it will be understood that the example process (600) may be performed, for example, by any system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some implementations, the steps of the example process (600) can be performed in parallel, in combination, in loops, or in any order.
    [0087] [0087] At (602), a consensus node receives transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deducting the transaction amount from a total value of the plurality of assets, the transaction amount and a third random number encrypted by a public key of the second node based on a probabilistic scheme HE, the alteration and a fourth random number encrypted by a key public key of the first node based on the probabilistic scheme HE, one or more interval proofs, a ZKP and a digital signature generated based on a private key corresponding to the public key of the first node.
    [0088] [0088] In some implementations, each of the plurality of assets is associated with one or more asset types, an asset value hidden in a commitment, and a random number used to generate the commitment. In some implementations, the consensus node determines that each of the plurality of assets is associated with the same asset type. In some implementations, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic.
    [0089] [0089] In some implementations, the third random number is encrypted based on the probabilistic scheme HE, treating the transaction value as a random number, and the fourth random number is encrypted based on the probabilistic scheme HE, treating the change as a number random. In some implementations, the first compromise and second compromise are generated based on a Pedersen compromise scheme, and the HE probabilistic scheme is an OU encryption scheme.
    [0090] [0090] In some implementations, the ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the encryption scheme of the OU, and a ciphertext of the fifth random number and sixth random number encrypted by the public key of the first account based on the OU encryption scheme.
    [0091] [0091] At (604), the consensus node verifies the digital signature based on the public key of the first node.
    [0092] [0092] In (606), the consensus node determines that one or more interval proofs prove that the transaction amount and change are greater than, or equal to, zero.
    [0093] [0093] In (608), the consensus node determines that the total value of the plurality of notes is equal to the sum of the transaction and change value. In some implementations, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is performed based on the homomorphism of the commitment scheme.
    [0094] [0094] In (610), the consensus node determines, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the value of the transaction hidden in the first appointment is equal to the transaction amount encrypted by the public key of the second node.
    [0095] [0095] In some implementations, the transaction is executed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, the account associated with the first node and the account associated with the second node based on transaction amount and change. In some implementations, the ZKP is generated and used to determine that the transaction is valid based on the probabilistic properties of HE. In some implementations, the determination that the transaction is valid is performed based on ZKP with no interactions between the first and second nodes through the trust protocol network.
    [0096] [0096] Figure 7 illustrates an example process (700) that can be performed according to implementations of the invention. For clarity of presentation, the description that follows generally describes method (700) in the context of the other figures in this description. However, it will be understood that the example process (700) may be performed, for example, by any system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some implementations, the steps of the example process (700) can be performed in parallel, in combination, in loops, or in any order.
    [0097] [0097] At (702), a consensus node receives transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deducting the transaction amount from a total value of the plurality of assets, the transaction amount and a third random number encrypted by a public key of the second node based on a linear deterministic scheme HE, the alteration and a fourth random number encrypted by a First node public key based on the linear deterministic scheme HE, one or more range proofs, a ZKP and a digital signature generated based on a private key corresponding to the public key of the first node.
    [0098] [0098] In some implementations, each asset plurality is associated with one or more asset types, an asset value hidden in a commitment, and a random number used to generate the commitment. In some implementations, the consensus node determines that each asset plurality is associated with the same asset type. In some implementations, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic.
    [0099] [0099] In some implementations, the linear deterministic HE scheme is derived from a probabilistic HE scheme based on changing a random number associated with the HE probabilistic scheme to a fixed number.
    [00100] [00100] In some implementations, the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the linear deterministic scheme HE , and a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the linear deterministic scheme HE.
    [00101] [00101] At (704), the consensus node verifies the digital signature based on the public key of the first node.
    [00102] [00102] In (706), the consensus node determines that one or more interval proofs prove that the transaction amount and change are each greater than or equal to zero.
    [00103] [00103] In (708), the consensus node determines that the total value of the plurality of notes is equal to the sum of the transaction and change value. In some implementations, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is performed based on the homomorphism of the commitment scheme.
    [00104] [00104] In (710), the consensus node determines, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the value of the transaction hidden in the first appointment is equal to the transaction amount encrypted by the public key of the second node.
    [00105] [00105] In some implementations, the transaction is executed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, the account associated with the first node and the account associated with the second node based on transaction amount and change. In some implementations, the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE. In some implementations, the determination that the transaction is valid is performed based on ZKP with no interactions between the first and second nodes through the trust protocol network.
    [00106] [00106] Figure 8 illustrates an example of a trusted protocol node (800) that can perform a process according to implementations of the invention. At a high level, the trust protocol node (800) includes a receiver unit (802), a verification unit (804), a first determination unit (806), a second determination unit (808) and a third unit of determination (810).
    [00107] [00107] In some implementations, the receiving unit (802) is operable to receive transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deduction of the transaction amount from a total amount of the plurality of assets, the transaction amount and a third random number, both encrypted by a public key of the second node based on a probabilistic scheme HE, the alteration and a fourth random number, both encrypted by a public key of the first node based on the probabilistic scheme HE, one or more range proofs, a ZKP and a digital signature generated based on a private key corresponding to the public key of the first node.
    [00108] [00108] In some implementations, the receiving unit (802) is operable to receive transaction data associated with the transaction, the transaction data comprises: data representing a plurality of assets, a first commitment that hides a first random number and a value transaction transaction value, second commitment that hides a second random number, and a change calculated based on deducting the transaction amount from a full amount of the plurality of assets, the transaction amount and a third random number both encrypted by a public key of the second node based on a HE linear deterministic scheme, the alteration and a fourth random number both encrypted by a public key of the first node based on the HE linear deterministic scheme, one or more interval proofs, a ZKP and a digital signature generated with based on a private key corresponding to the public key of the first node.
    [00109] [00109] In some implementations, each asset plurality is associated with one or more asset types, an asset value hidden in a commitment, and a random number used to generate the commitment. In some implementations, the trust protocol node (800) determines that each plurality of assets is associated with the same asset type. In some implementations, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic. In some implementations, the linear deterministic HE scheme is derived from a HE probabilistic scheme based on changing a random number associated with the HE probabilistic scheme to a fixed number.
    [00110] [00110] In some implementations, the third random number is encrypted based on the probabilistic scheme HE, treating the transaction value as a random number, and the fourth random number is encrypted based on the probabilistic scheme HE, treating the change as a number random. In some implementations, the first compromise and second compromise are generated based on a Pedersen compromise scheme, and the HE probabilistic scheme is an OU encryption scheme.
    [00111] [00111] In some implementations, ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the encryption scheme of the OU, and a ciphertext of the fifth random number and sixth random number encrypted by the public key of the first account based on the OU encryption scheme. In some implementations, the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the linear deterministic scheme HE, and a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the linear deterministic scheme HE.
    [00112] [00112] The verification unit (804) is operable to verify the public key-based digital signature of the first node.
    [00113] [00113] The first determination unit (806) is operable to determine one or more interval probes that prove that the transaction amount and the change are each greater than or equal to zero.
    [00114] [00114] The second determination unit (808) is operable to determine that the total value of the plurality of notes is equal to the sum of the transaction and change value. In some implementations, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is performed based on the homomorphism of the commitment scheme.
    [00115] [00115] The third determination unit (810) is operable to determine, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the transaction amount hidden in the first appointment is equal to the transaction amount encrypted by the public key of the second node.
    [00116] [00116] In some implementations, the transaction is performed between an account associated with the first node and an account associated with the second node, and the trust protocol node (800 ) may include an operable update unit for update, after the third unit determining (810) determines that the transaction is valid, the account associated with the first node and the account associated with the second node based on the transaction amount and the change. In some implementations, the ZKP is generated and used to determine that the transaction is valid based on the HE probabilistic properties. In some implementations, the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE. In some implementations, the determination that the transaction is valid is performed based on ZKP with no interactions between the first and second nodes through the trust protocol network.
    [00117] [00117] The implementations of the subject described in this specification can be implemented so as to realize particular advantages or technical effects. For example, implementations of the invention allow the account balance and transaction value of the trust protocol nodes to be private during transactions. The funds transfer recipient does not need to confirm the transaction or use a random number to verify a commitment, transaction validation may be non-interactive. A trust protocol node can validate the transaction based on the HE and commitment schemes to allow proof of zero knowledge.
    [00118] [00118] The described methodology allows for the enhancement of account/data security of various mobile computing devices. Account balance and transaction amounts can be encrypted based on HE and hidden by confirmation schemes. As such, a consensus node can update account balances in the registry after the transaction based on the properties of the HE, without revealing the current account balance. As the random number does not need to be sent to a recipient to confirm the transaction,
    [00119] [00119] The implementations and operations described in this specification may be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this specification or in combinations of one or more of them. Operations may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources. A data processing device, computer or computing device may encompass apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or various, or combinations, of the foregoing. The apparatus may include special purpose logic circuitry, for example, a central processing unit (CPU), a programmable field gate array (FPGA), or an application-specific integrated circuit (ASIC). The apparatus may also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system (for example, , an operating system or a combination of operating systems), a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The appliance and execution environment can realize many different models of computing infrastructures such as web services, distributed computing, and grid computing infrastructures.
    [00120] [00120] A computer program (also known,
    [00121] [00121] Processors for executing a computer program include, by way of example, general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from read-only memory or random access memory, or both. The essential elements of a computer are a processor to perform actions according to instructions and one or more memory devices to store instructions and data. Generally, a computer will also include, or be operatively coupled to receive data or transfer data to, or both, one or more mass storage devices for storing data. A computer can be embedded in another device, for example, a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver or a portable storage device.
    [00122] [00122] Mobile devices may include handset, user equipment (EU), mobile phones (eg smartphones), tablets, wearable devices (eg smart watches and smart glasses), devices implanted in the human body (eg , biosensors, cochlear implants) or other types of mobile devices. Mobile devices can communicate wirelessly (for example, using radio frequency (RF) signals) to various communication networks (described below).
    [00123] [00123] To provide interaction with a user, implementations can be implemented on a computer with a display device and an input device, for example, a liquid crystal display (LCD) or organic light-emitting diode (OLED) / virtual reality (VR)/ augmented reality (AR) display to display information to the user and a touch screen, keyboard and pointing device by which the user can provide input to the computer.
    [00124] [00124] Implementations may be implemented using computing devices interconnected by any form or means of wired or wireless digital data communication (or combination thereof), eg, a communication network. Examples of interconnected devices are a client and a server that are usually remote from each other and that normally interact through a communication network. A customer, for example, a mobile device, can carry out transactions itself, with a server or through a server, for example, carrying out purchase, sale, payment, delivery, shipment or loan transactions, or by authorizing the same. Such transactions can be real-time, so that an action and a response are temporarily close together; for example, an individual perceives the action and the response occurring substantially simultaneously, the time difference for a response after the individual's action is less than 1 millisecond (ms) or less than 1 second (s), or the response is without delay intentions of system account processing limitations.
    [00125] [00125] Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN) and a wide area network (WAN). The communication network can include all or part of the Internet, another communication network or a combination of communication networks. Information can be transmitted over the communication network in accordance with various protocols and standards, including Long Term Evolution (LTE), 5G, IEEE 802, Internet Protocol (IP) or other protocols or combinations of protocols. The communication network may transmit voice, video, biometric or authentication data or other information between connected computing devices.
    [00126] [00126] Features described as separate implementations can be implemented, in combination, in a single implementation, while features described as a single implementation can be implemented in multiple implementations, separately or in any suitable subcombination. Operations described and claimed in a specific order should not be understood as requiring the specific order, nor that all illustrated operations be performed (some operations may be optional). As appropriate, multitasking or parallel processing (or a combination of multitasking and parallel processing) can be performed.
    权利要求:
    Claims (12)
    [1]
    1. COMPUTER IMPLEMENTED METHOD performed by a consensus node to validate a transaction between a first node and a second node within a trusted protocol network, the method characterized by comprising: receiving transaction data associated with the transaction, the data of the transaction comprises: data representing a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a change calculated based on the deduction of the transaction amount from a total value of the plurality of assets, the transaction amount, and a third random number both encrypted by a public key of the second node based on a probabilistic homomorphic (HE) encryption scheme, the alteration, and a fourth random number both encrypted by a public key of the first node based on the probabilistic scheme HE, one or more interval proofs, a proof of c zero knowledge (ZKP) and a digital signature generated based on a private key corresponding to the public key of the first node; verify the digital signature based on the first node's public key; determine that one or more range proofs prove that the transaction amount and the change are each greater than or equal to zero; determine that the total value of the plurality of assets is equal to a sum of the transaction value and the change; and determine, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the transaction amount hidden in the first appointment equals the amount transaction encrypted by the public key of the second node.
    [2]
    2. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the operation is performed between an account associated with the first node and an account associated with the second node, and the method further comprising updating, after determining that the transaction is valid, from the account associated with the first node and the account associated with the second node based on transaction amount and change.
    [3]
    3. COMPUTER IMPLEMENTED METHOD, according to claim 1, characterized in that each plurality of assets is associated with one or more than one type of asset, an asset value hidden in an appointment, and a random number used to generate the commitment .
    [4]
    4. METHOD IMPLEMENTED BY COMPUTER, according to claim 3, characterized in that it further comprises the determination that each plurality of assets is associated with the same type of asset.
    [5]
    5. METHOD IMPLEMENTED BY COMPUTER, according to claim 3, characterized in that the first commitment, the second commitment and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic, and in which the determination of that the total value of the plurality of assets is equal to the sum of the transaction value and the alteration is performed based on the homomorphism of the commitment scheme.
    [6]
    6. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the third random number is encrypted based on the probabilistic scheme HE, treating the transaction amount as a random number, and the fourth random number is encrypted based on the probabilistic scheme HE, treating the change as a random number.
    [7]
    7. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the first commitment and the second commitment are generated based on a Pedersen commitment scheme and the probabilistic HE scheme is an Okamoto-Uchiyama (OU) encryption scheme.
    [8]
    8. METHOD IMPLEMENTED BY COMPUTER, according to claim 7, characterized in that the ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a ciphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the OU encryption scheme, and a ciphertext of the fifth random number and sixth random number encrypted by the public key of the first account based on the OU encryption scheme.
    [9]
    9. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that ZKP is generated and used to determine that the transaction is valid based on the probabilistic properties HE.
    [10]
    10. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized by the determination that the transaction is valid to be performed based on the ZKP without interactions between the first node and the second node through the trusted protocol network.
    [11]
    11. COMPUTER-READABLE, NON-TRANSIENT STORAGE MEANS, characterized in that it is coupled to one or more computers and configured with instructions executable by one or more computers to perform operations in accordance with the method, as defined in any one of claims 1 to 10.
    [12]
    12. SYSTEM, characterized by comprising:
    one or more computers; and one or more computer readable memories coupled to one or more computers and configured with instructions executable by one or more computers to perform operations in accordance with the method,
    as defined in any one of claims 1 to 10.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019016474A2|2021-06-29|computer implemented method, computer readable non-transient storage medium and system
    ES2881319T3|2021-11-29|Blockchain Data Protection Using Homomorphic Encryption
    US11063769B2|2021-07-13|Blockchain data protection based on generic account model and homomorphic encryption
    BR112019008160B1|2021-08-24|COMPUTER IMPLEMENTED METHOD EXECUTED BY A CONSENSUS NODE OF A BLOCK CHAIN NETWORK, COMPUTER-READABLE STORAGE MEDIA, AND SYSTEM TO IMPLEMENT A METHOD
    ES2876926T3|2021-11-15|Blockchain data protection using homomorphic encryption
    同族专利:
    公开号 | 公开日
    CA3052997C|2021-01-26|
    EP3566197A2|2019-11-13|
    AU2018347201A1|2020-07-09|
    JP2020515885A|2020-05-28|
    US10708039B1|2020-07-07|
    PH12019501849A1|2020-03-09|
    ZA201905220B|2020-05-27|
    US20190327078A1|2019-10-24|
    WO2019072300A2|2019-04-18|
    RU2719451C1|2020-04-17|
    CN111602161A|2020-08-28|
    US10680800B2|2020-06-09|
    KR20200079219A|2020-07-02|
    SG11201907281WA|2019-09-27|
    CA3052997A1|2019-04-18|
    EP3566197A4|2020-03-11|
    JP6811334B2|2021-01-13|
    KR102213414B1|2021-02-09|
    WO2019072300A3|2019-10-24|
    US20200195419A1|2020-06-18|
    AU2018347201B2|2020-08-27|
    MX2019009412A|2019-10-02|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US5394116A|1993-12-29|1995-02-28|At&T Corp.|Fractional phase shift ring oscillator arrangement|
    IT1284718B1|1996-07-31|1998-05-21|Cselt Centro Studi Lab Telecom|DEVICE AND PROCEDURE FOR TEMPORARILY ALIGNING NUMERICAL SIGNALS, FOR EXAMPLE A CLOCK SIGNAL AND A FLOW OF DATA.|
    FR2800220B1|1999-10-26|2002-02-15|France Telecom|SECURE ELECTRONIC TRANSACTION PROCESS|
    US20090327141A1|2007-04-18|2009-12-31|Rabin Michael O|Highly efficient secrecy-preserving proofs of correctness of computation|
    US20090177591A1|2007-10-30|2009-07-09|Christopher Thorpe|Zero-knowledge proofs in large trades|
    EP2590126A1|2011-11-01|2013-05-08|Nederlandse Organisatie voor toegepast -natuurwetenschappelijk onderzoek TNO|Recommender system for providing recommendations to groups of users|
    US20150242825A1|2014-02-24|2015-08-27|Peter Burton Mills|Generation, storage, and validation of encrypted electronic currency|
    WO2016076934A2|2014-08-22|2016-05-19|Thomas John K|Verification system for secure transmission in a distributed processing network|
    US10257173B2|2014-10-22|2019-04-09|Openeye Scientific Software, Inc.|Secure comparison of information|
    WO2016200885A1|2015-06-08|2016-12-15|Blockstream Corporation|Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction|
    RU2015145232A|2015-10-21|2017-05-03|Дмитрий Сергеевич Ермолаев|METHOD FOR ACCOUNTING AND STORAGE OF TEMPORARY ACCOUNTING UNITS IN SINGLE-LEVEL BLOCKCHAIN MEDIA|
    US11042878B2|2016-01-19|2021-06-22|Priv8Pay, Inc.|Network node authentication|
    US10846984B2|2016-02-24|2020-11-24|Uplay1|Casino crypto currency systems and methods|
    US10046228B2|2016-05-02|2018-08-14|Bao Tran|Smart device|
    US9635000B1|2016-05-25|2017-04-25|Sead Muftic|Blockchain identity management system based on public identities ledger|
    CN107438002B|2016-05-27|2022-02-11|索尼公司|Block chain based system and electronic device and method in system|
    US10243731B2|2017-01-27|2019-03-26|Accenture Global Solutions Limited|Hardware blockchain acceleration|
    KR101879353B1|2017-01-31|2018-07-17|권양호|Mediation Service System and Method using Virtual Money|
    US10832230B2|2017-04-04|2020-11-10|International Business Machines Corporation|Scalable and distributed shared ledger transaction management|
    US10277395B2|2017-05-19|2019-04-30|International Business Machines Corporation|Cryptographic key-generation with application to data deduplication|
    US10761877B2|2017-07-21|2020-09-01|Intel Corporation|Apparatuses, methods, and systems for blockchain transaction acceleration|
    CN107656812A|2017-09-27|2018-02-02|咪咕文化科技有限公司|block chain processing method, system, node device, terminal and storage medium|
    CN108021821A|2017-11-28|2018-05-11|北京航空航天大学|Multicenter block chain transaction intimacy protection system and method|
    US10833861B2|2017-11-28|2020-11-10|International Business Machines Corporation|Protection of confidentiality, privacy and ownership assurance in a blockchain based decentralized identity management system|
    WO2019109003A1|2017-11-30|2019-06-06|Visa International Service Association|Blockchain system for confidential and anonymous smart contracts|
    CN108418689B|2017-11-30|2020-07-10|矩阵元技术（深圳）有限公司|Zero-knowledge proof method and medium suitable for block chain privacy protection|
    EP3741082B1|2018-01-19|2021-12-29|Qed-It Systems Ltd.|Proof chaining and decomposition|
    EP3522064B1|2018-02-02|2021-12-22|Università Degli Studi Di Trento|A method and apparatus for distributed, privacy-preserving and integrity-preserving exchange, inventory and order book|
    US20190251527A1|2018-02-14|2019-08-15|Christopher Walter Surdak|System, Method, and Computer Program Product for a Distributed, Cryptographically Secured Proof-of-Intent Transaction Network|
    CN108764874B|2018-05-17|2021-09-07|深圳前海微众银行股份有限公司|Anonymous transfer method, system and storage medium based on block chain|
    CN109035029A|2018-07-27|2018-12-18|阿里巴巴集团控股有限公司|Based on the assets transfer method and device of block chain, electronic equipment|
    CN109039648B|2018-08-03|2021-09-03|克洛斯比尔有限公司|Block chain creating method and device and readable storage medium|
    MX2019009412A|2018-12-21|2019-10-02|Alibaba Group Holding Ltd|Blockchain data protection based on generic account model and homomorphic encryption.|
    CN110402561B|2018-12-21|2021-11-23|创新先进技术有限公司|Block chain data protection based on general account model and homomorphic encryption|US10771237B2|2017-01-20|2020-09-08|Enveil, Inc.|Secure analytics using an encrypted analytics matrix|
    US20180212753A1|2017-01-20|2018-07-26|Enveil, Inc.|End-To-End Secure Operations Using a Query Vector|
    US10693627B2|2017-01-20|2020-06-23|Enveil, Inc.|Systems and methods for efficient fixed-base multi-precision exponentiation|
    US11196541B2|2017-01-20|2021-12-07|Enveil, Inc.|Secure machine learning analytics using homomorphic encryption|
    US10902133B2|2018-10-25|2021-01-26|Enveil, Inc.|Computational operations in enclave computing environments|
    US10817262B2|2018-11-08|2020-10-27|Enveil, Inc.|Reduced and pipelined hardware architecture for Montgomery Modular Multiplication|
    CN110402561B|2018-12-21|2021-11-23|创新先进技术有限公司|Block chain data protection based on general account model and homomorphic encryption|
    MX2019009412A|2018-12-21|2019-10-02|Alibaba Group Holding Ltd|Blockchain data protection based on generic account model and homomorphic encryption.|
    CN110414985A|2019-06-12|2019-11-05|阿里巴巴集团控股有限公司|A kind of detection method and device of exception account|
    US10778410B2|2019-06-18|2020-09-15|Alibaba Group Holding Limited|Homomorphic data encryption method and apparatus for implementing privacy protection|
    CN110348231B|2019-06-18|2020-08-14|阿里巴巴集团控股有限公司|Data homomorphic encryption and decryption method and device for realizing privacy protection|
    US10790990B2|2019-06-26|2020-09-29|Alibaba Group Holding Limited|Ring signature-based anonymous transaction|
    CN110545279A|2019-09-05|2019-12-06|国网区块链科技有限公司|block chain transaction method, device and system with privacy and supervision functions|
    EP3799644A4|2020-02-03|2021-06-09|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    SG11202013136SA|2020-02-03|2021-01-28|Alipay Hangzhou Information Technology Co Ltd|Blockchain-based trustable guarantees|
    EP3794483A4|2020-02-03|2021-04-28|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    NL2026713B1|2020-10-20|2021-12-14|Shenzhen Polytechnic|A Blockchain Privacy Protection System and Its Method|
    法律状态:
    2021-08-10| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-08-31| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |
    优先权:
    申请号 | 申请日 | 专利标题
    PCT/CN2018/122539|WO2019072300A2|2018-12-21|2018-12-21|Blockchain data protection based on generic account model and homomorphic encryption|
    [返回顶部]